2.5.136 Maintenance Release Notes

Enhancements

  • Fields with a Core Field Code are available for the Bind To option in the Business Rules section when managing fields in a Claims workflow. This option allows the field to be mapped to a core field in the system. Additionally, when creating new fields to map to the Claims core fields, users can set a default value. The default value can be set using either a constant or an expression value. For details on setting the Bind To option for claims fields, see the Configuring a Claims Workflow section.

  • The Bridge Specialty Suite has been updated with more restrictive access to certain settings files in order to enhance the security of the application. For additional details, please contact your Insurity Account Representative.

  • The Batch Import Template has been updated to include the Bill To Party Code field. Additionally, the Bill to Party Code field is now included as a validation criteria for the Policy Term when performing a Batch Import.

Fixes

  • Users who recently updated their Chrome browser to version 86.0.4240.75 (Official Build) (64-bit) released on 2020-10-07 were presented a blank login page when accessing the Bridge Specialty Suite. Investigation found that there was an error in the JavaScript of the page that was coming from the Chrome update. The new Chrome engine changed the handling of empty event handler attributes for the “onchange” and “onblur” events, typically used by text fields to add custom UI behaviors. The new browser was able to detect when the events did not have custom JavaScript specified, and optimized the initialization of the control by assigning native “no-op” handlers with no equivalent JavaScript code. This prevented ASP.Net code from chaining validator JavaScript to the existing event handlers. This resulted in the browser being unable to load most pages in the application. The issue has been resolved by omitting the unnecessary event handler attribute in the case of an empty body.
  • Users were unable to offset the outstanding amount for invoices on the Aged Receivables report in the Billing module of the Bridge Specialty Suite, and the Aged Receivables report did not match the Outstanding Balance on the account. The Outstanding Amounts on this report are calculated by querying the receipt allocations for the invoices. As part of this calculation, the system must ignore any allocations that have been reversed. The logic for filtering out the reversals was not working and reversal receipt amounts were being added to the invoice Outstanding Amounts. A code change was applied to the Billing module to exclude the reversal of receipt allocations for the Aged Receivables report.
  • Users creating submissions via API were presented an error message, DistributorReferenceCode is Null. This placeholder is usually populated when submissions are created via the UI. Also, when attempting to quote a submission in the UI that was created via API, an error message related to the Distributor was presented. Finally, when trying to access the Premium widget for a submission that was quoted through the API, a server error was displayed. The issues were introduced by a previous code change to field codes, that subsequently caused the errors to occur in Domain APIs. The error caused the service to fail to map the premium grid in the request, and therefore premiums were not updated. The errors have been addressed by a code change.
  • The automatic job responsible for processing Auto-Renewals was not working. An error occurred in the job queue for automatic renewals and the policies were not being found. Investigation found that the source of the error was in the initial web service call which attempted to re-post a job using an API which was unavailable. Additionally, a high volume of automatic jobs awaiting to be executed caused the error. There was no code fix required for this error as once the job queue was cleared, the Auto-Renewal job executed as expected.
  • When the Invoice Future Installments When OAB Is Available setting is enabled in the Billing settings, the system was issuing invoices for Quoted submissions that have not been Bound. The system would generate an invoice for one charge and apply the cash to that invoice, even though the submission was not yet bound. The issue was caused when introducing the above setting so that Pending charges would be considered when the system tried to find all charges that would be invoiced based on the above setting, and then mark them as booked once the transaction was bound. The issue has been corrected by a code change applied to the system so that charges are only invoiced if the transaction has been successfully bound.
  • Users accessing the Bridge Specialty Suite in the Edge browser encountered an error where any page containing a grid would not display the full rows in the grid, as it does on the Chrome and Firefox browsers. The issue was caused by the CSS rendering of the height of the grid that would set it to a predetermined height, and therefore could not display all rows on the page. The issue has been correct by a code fix to override the height of the grid to be set automatically in order to show all items in the grid without a scroll bar.
  • If a New Business transaction was created with an expiry date that fell on a leap year (February 29th), and users tried to import an ERP policy term using the ImportPolicy web service, the system would throw an error and import would fail. The issue occurred because the system is expecting the dates to match. The validation of the ERP Endorsement Duration setting does not consider that the last policy term's valid until date is a leap year, and the ERP's Valid Until Date is a non-leap year date (February 28th), so when the system compares the dates, it doesn't match. The issue was corrected by a code fix.
  • The DetectChanges function was not evaluating properly on subsequent policy endorsements. Note that the Request Management checkbox and Endorsement Type were set to Do Not Copy as a carry forward rule, and must be manually selected. This resulted in new rows in DetectChanges section of Formula Evaluator not being added. A code fix was applied so that only changes that match a value queried for the DetectChanges formula are copied instead of all data being copied, as per previous functionality.
  • The DetectChanges function was not evaluating properly for the Insured Company Name field. The DetectChanges function is used to determine if any changes have been made to the field(s) passed to it since the last time the function was evaluated. In this case, the function was being called when saving the assured, and then a second time when loading a page, but since the values had already been recorded and saved in the database, the function returned false, even though changes had been made. A suggestion to mitigate this issue, is to wrap the core Assured field in a calculated field. This way when the value is passed when loading the page, it will verify, for the first time, if any changes occurred.
  • When adding security rights to a security role in the Bridge Specialty Suite, upon saving and closing the modal, the system should save the assigned rights to that role. An error occurred where users would not see the right(s) they added to the role after saving and reopening the security role. The investigation discovered that there was an issue in the ICS (Insurity Common Security) component that was creating a duplicate of the security right that was added, in the database. A data correction was done to resolve the issue.
  • Licensees using the Billing History summary page in Client Center were unable to view this page as expected. The issue is caused because Client Center retrieves the Billing History data from a Billing web API, and the Billing web API sets the Billing Entity to the Default Billing Entity, and as a result only the Account History for the Default Billing Entity is returned. This is because Client Center does not have the Billing Entity logic and cannot determine between the default and specified entity. To remedy this issue, users must retrieve the Billing Entities linked to the Bill to Party (Client) that is passed in the Web API in order to return the Billing History for the Client.
  • When using the API to retrieve a collection of grid rows, the collection is returned but without any data. The issue occurred because of a code change to the Data Comparison format in the API, where it was changed from singular format to plural. This resulted in the data not being found. A code fix has been implemented to address the issue.

  • When attempting to import Deductible Charges through the web service, the integration between ClaimsXPress and the Bridge Specialty Suite failed because the web service could not identify the Billing Entity based on the type of transaction. For importing deductible charges, the service was expecting the Billing Entity code to be passed as a parameter, which is not desired behavior. The expectations of the feature required the service to identify the Billing Entity through the Policy Transaction (using the Policy Transaction ID). A code change was applied to the Billing module to make it possible for the ImportCharges web service to determine the Billing Entity through policy transaction.

    Note that the change was made in a way that the service is backwards compatible. That means if the policy transaction cannot be found in the system using the Transaction ID that is passed in the request, the service still considers the Billing Entity Code in the request. This is the case when deductible charges are imported into the system for new policies that do not exist in the Billing module. However, if a policy transaction can be identified in the system using the Transaction ID, the Billing Entity is determined through the policy transaction.

  • A server error was presented to users who clicked on Save while working on a submission in the system. This error is related to an exception that occurred in the system when updating Distributor fields and then calculating the quote. The same code fix has been applied to address this issue.
  • The custom field LossDate which is stored in the Bridge database seems to have an offset added when integration is done with CXP. The exported bridge field does not have the same Loss Date in the CXP Claim as the Reported Date in the given field. The Loss Date in CXP is one day prior to the Reported Date entered in bridge claims fields. A code fix was applied to ensure that the date being passed to CXP was accurately taking time offset into consideration and returning expected values.
  • Submissions created via API are not evaluating behavior triggers as expected. Panel behaviors that are configured should work the same whether the submission is created via the UI or API. The issue was caused by a code change to address the reloading of the XML and Formula Evaluator unnecessarily. A code fix to address the submission issue has been implemented.
  • Certain licensees were unable to see the Effective Date in the Policy Information widget when accessing an Endorsement transaction. Investigation revealed that the issue was caused by a configuration setting.